昨天 Day 01 講了心法：AI 可以幫你把槓鈴舉起來，但肌肉要自己練。

今天講工具怎麼配置。為什麼用了兩個 AI 來協助。

一、先講兩個容易踩的坑

坑 1：拿寫程式的 AI 來聊天

你腦中有個模糊的想法：

「我想做個卡牌遊戲，好像可以有護甲，然後打魔王……」

你直接打開 VS Code 裡的 Claude Code 開始聊。
聊了二十輪，想法終於清楚了。
但這二十輪對話裡，可能充滿：

「我覺得這樣好像不太好。」
「不然改成那樣。」
「等等，剛剛那個先不要。」

等真正要寫程式時，AI 還得先從這些被推翻的想法裡，分辨哪些才算數。

額度花掉了，產出品質也可能下降。

坑 2：把整份討論直接丟給 AI

另一個極端，是先在別的地方討論好，再把幾千字的對話全部貼過去：

「照這個做。」

但 AI 收到的是一份會議逐字稿，不是規格書。
它還是得自己判斷：

哪些是結論？
哪些只是討論過程？
哪些已經被否決？

判斷錯了，就可能做出你不要的東西。

二、我的分工原則：探索和施工分開

我後來整理出一個很簡單的分工方式：

需要大量來回討論的工作，先交給 Chat AI。
需要讀取、修改、執行現有專案的工作，交給 Coding Agent。

在這次實驗裡，我使用 Gemini 負責前期討論，Claude Code 負責實際施工。

原因很簡單：規劃遊戲時，常常要來回討論很多次，最後才留下幾段結論；但開始寫程式後，我希望 AI 能直接讀目前的檔案、修改程式、執行測試。

所以可以簡單理解成：

聊天是高來回、低產出；施工是低來回、高產出。

因此，我會把大量探索放在 Chat AI，把需要直接操作專案的工作放在 Coding Agent。

三、我實際是怎麼做的？

這個專案一開始，我分成四個階段。

1. 在 Gemini 隨便聊

我的第一句話很簡單：

「想開發自己的 Roguelike 卡片文字遊戲，你有什麼建議，最簡單的遊戲會是什麼」

沒有規格、沒有需求文件，就是一句模糊的想法。接下來五百多行，我一路討論：

完全零基礎該用什麼引擎？
遊戲只有血量、護甲、攻擊力夠不夠？
能不能簡化成只有一個敵人？

這個階段可以隨便講，也可以隨時改口。
因為還沒有程式碼，推翻想法沒有什麼成本。
所以這類需要大量來回、還沒有明確答案的探索工作，我會先放在 Chat AI。

2. 收斂成一個決定

聊到後來，我丟出這句話：

「那最簡單的是不是，一場只有一個敵人，就是魔王，然後我會撿 10 個寶箱拿到卡片，然後最後決戰大魔王」

這就是《異世界救援》的雛形。
原本很大的想法，開始變成一個可以真的做出來的遊戲。

怎麼從龐大的野心縮到這一步，是 Day 03 的主題。

3. 把對話「編譯」成文件

想法清楚之後，我沒有把五百行對話直接丟給 Claude Code。

我對 Gemini 說：

「先幫我寫一個專案的 md」

最後產出了一份 README.md，裡面整理了核心機制、三個數值的定義、卡牌流派、專案目錄結構，以及開發路線。

五百行對話，變成一份兩百行左右的規格文件。

這一步很重要。
因為：

對話是過程，規格才是結果。

前面的聊天可以很亂，可以反覆修改；但交給工程師之前，我需要先把「最後決定了什麼」整理清楚。

4. 交棒給 Claude Code

接著我對 Gemini 說：

「好，我在目錄建好 readme.md 用 vscode 開了目錄，我要怎麼叫 claude 開始工作，你現在是指揮 claude 的人，目前沒裝過 Godot」

Gemini 接著幫我整理出一份可以直接交給 Claude Code 的指令。

我把指令貼進 VS Code 裡的 Claude 對話介面。
Claude Code 收到後，安裝了 Godot、建立專案骨架，也寫出了第一批 .gd 檔案。

這時候工作型態已經不一樣了。
前面是在討論「要做什麼」；現在是要讓 AI 直接讀取專案、建立檔案、修改程式並執行工作。
所以這裡我才把工作交給 Coding Agent。

整個過程，我沒有寫過一行程式碼，也沒有自己組過一句技術 Prompt。

四、讓 AI 幫你寫給另一個 AI 的指令

這可能是整套流程裡，很方便拿走的一個方法。
當你跟 Gemini 討論完，不要直接把整份對話貼給工程 AI。
可以改成：

「請把我們剛才討論的內容，整理成一份給 VS Code 裡的 AI 工程師執行的精簡指令，要包含：

1. 核心需求
2. 需要宣告的變數與數值
3. 要實作的函式與邏輯邊界」

這會逼 Gemini 把前面的討論重新整理一次：

篩掉被推翻的想法 → 整理結論 → 變成工程師看得懂的指令。

最後拿到的就不是逐字稿，而是一份可以直接交給工程 AI 執行的規格指令。

五、但這個規則不是絕對的

後來真正開始開發後，我發現有一個很重要的例外：

如果問題需要知道目前專案的實際狀態，就算討論很多輪，也應該留在 Coding Agent。

例如後來討論 Boss 連續戰鬥時，我需要先確認：

• ALTAR_OUTCOMES 現在有哪些設定
• Global.gd 怎麼處理攻擊力
• player_attack 是由哪些數值組成
• player_hp 和 player_max_hp 怎麼分開處理

這些不是單純的遊戲設計問題，而是：

「現在這個專案到底是怎麼寫的？」

Claude Code 可以直接讀目前的檔案，再跟我一起討論。
如果換成 Chat AI，我就得先把相關程式碼貼過去，否則它只能猜。

所以後來我的分工原則變成：

還沒有專案，需要大量探索 → Chat AI
已經有專案，需要確認目前程式狀態 → Coding Agent
需要直接修改、執行、測試 → Coding Agent

這比單純說「Gemini 負責思考、Claude 負責寫程式」更準確。

六、不是模型個性，是產品定位

實際使用後，我發現 Gemini 比較適合陪我發想，而 Claude Code 的互動方式則比較直接，常常會往「開始修改程式」的方向走。

一開始我以為這是「模型個性不同」。
後來才發現，我比較的其實是兩個不同定位的產品。

而這個差異，對我來說最直接的影響，其實是AI的使用成本。
我原本很容易把 Coding Agent 當成聊天工具。
想到一個問題就問，想到另一個問題再問，20 輪之後才發現：

額度已經用了很多，但真正留下來的程式碼沒多少。

所以後來我才開始刻意把兩種工作分開：

把大量探索和來回討論，放在適合聊天的工具。
把需要直接操作專案的工作，留給 Coding Agent。

不是因為其中一個 AI 比另一個聰明。
而是：

選對工具，比一直換模型更重要。

你不一定要用 Gemini + Claude Code。

只要找到一個適合「聊天與發想」的工具，以及一個能「讀寫專案、直接施工」的工具，就可以使用同樣的概念。

七、今天的結論

這一天真正留下來的，其實只有幾件事：

• 第一，先把聊天和施工分開。
• 第二，不要把雜亂的對話直接交給工程 AI，先整理成規格。
• 第三，專案建立之後，如果問題需要查現有程式碼，就算討論很多輪，也應該留在編碼代理裡。

實際使用下來，我發現 Gemini 和 Claude Code 的分工只是我這次實驗採用的一種方式。
你不一定要用 Gemini + Claude Code，也可以從頭到尾使用同一個 AI。
對我來說，比較重要的改變是，我開始注意哪些事情適合先討論，哪些事情適合直接進入專案處理。

這個專案到了後面，聊天介面會越來越少出現。
因為規劃已經慢慢收斂，接下來大部分時間，都是直接施工。

而那份 README.md 也會變得越來越重要。
它不只是「專案說明」，而會慢慢變成 Claude Code 每次重新進入專案時，都可以讀到的長期保存的規格書。

至於一開始那個很大的遊戲夢想，最後到底是怎麼被砍成 10 個關卡？

明天 Day 03，我們來拆這件事。

💬 你會同時用好幾個 AI 嗎？還是習慣從頭到尾用同一個？歡迎留言聊聊。